Currently, in the optical network transmission process, the service transmission is vulnerable to adverse events such as fiber cut. In order to improve reliability of service transmission and improve the availability of the optical network, the corresponding protection actions must be taken in the optical transmission network in view of possible events unfavorable to service transmission. Generally, the protection action is to use standby resources to protect active resources. When the active resources fail, the corresponding service transmission is implemented through the standby resources.
Currently, a shared protection ring may be used to protect services in an Optical Transport Network (OTN). In the ITU_T G.783.2 recommendations, the shared protection ring of an Optical channel Data Unit of k order (ODUk) in an OTN is configured through the following steps:
1. Specifying the working channel ODUk to be protected on the protection ring. Corresponding to the working service, only one ODUk working service can exist between two nodes in pairs in a protection ring.
2. Numbering such working services.
3. Specifying the nodes of the protection ring. The nodes must be capable of adding or dropping working services or extra services in a protection ring.
4. Identifying extra services on a ring.
FIG. 1 is an example of configuring an ODUk protection ring. The box in FIG. 1 represents each NE node of the protection ring, the arrowhead means adding/dropping (which means inserting or extracting, and adding or reducing) a working service on the protection ring. The outer ring is a working channel, which bears four ODUk working services numbered 1, 2, 3 and 4. The inner ring is a protection channel, on which extra services are configured. The dashed line represents bandwidth not used in the protection group.
For the ODUk ring protection, when protection switching occurs on a ring, the nodes on the protection ring interact with each other through an Automatic Protection Switching (APS) byte. The APS byte is defined in FIG. 2, and the fields of the APS byte are defined below:
Request—priority of switching request;
S—the switching and status request value is 1, and the status notification value is 0;
N—the value of the local request is 0, and the value of the remote request is 1;
Requested Channel—channel requested to switch;
Bridged Channel—channel already bridged to the protection;
Status Channel—for status notification message only, indicating the channel related to the status message;
The value of a channel number is: 0=empty signal; 1˜254=ODUk working service number on the protection ring; 255=extra service signal.
Taking the service configuration in FIG. 1 as an example. When Signal Failure (SF) of receiving service 2 is detected on network element A, network element A sends a notification to all other nodes throughout the ring through an APS byte, and indicates a protection switching request for service 2 by assigning the value “2” to the Requested Channel field. In the subsequent interaction, a value “2” is assigned to the Bridged Channel field in the APS byte, if the switching node performs bridging for service 2. In a word, in the ODUk protection ring, the network elements interact with each other through an APS, while the APS byte uses a unique service number in the ring to indicate the bridge switching request for a specific service. The detailed protection switching process is described in ITU-T G.873.2 draft (200305).
In view of the configuration of the protection ring and the use of the APS byte in the protection switching process, the serial numbers of the working services on the ODUk protection ring are characterized by:
1. The service number of the ODUk of each working service is unique, and must not be duplicate.
2. A maximum of one working service may coexist on each segment of a protection ring, namely, may correspond to at most one service number.
3. Taking the request channel field in the APS byte as an example, a byte represents a service number, “0” indicates no switching request for the working service, and “255” indicates an extra service. Therefore, values of the serial number of working services range from 1 to 254.
The ITU-T recommendation sets forth the requirements such as the value range of the serial number a working service on the ODUk protection ring, and describes how to use the serial number to implement the interaction process of protection switching, but does not stipulate how to create such serial numbers automatically.
In the prior art, the concept of a ring chart in multiplex section protection in the Synchronous Digital Hierarchy/Synchronous Optical NETwork (SDH/SONET) and the method of creating such a ring chart automatically tend to be confused with the serial number of the working service. In the multiplex section protection ring in the SDH/SONET, a node number which is unique throughout the ring is configured for each node, and the value range of the node number is 0˜15. However, a ring chart of the multiplex section needs to be created for each node in the multiplex section ring. The ring chart specifies the nodes (identified by node numbers) on the multiplex section ring, and the topology relation of such nodes. A general method for creating a ring chart automatically is: The ring node sends a message, which is circulated around the protection ring, and terminated at the source node. Each ring node that circulates the message affixes the corresponding multiplex section node number to the message sequentially. When the message arrives at the source node, the ring chart of the whole multiplex section ring is understandable according to all ring nodes recorded in the message and the sequence of the ring nodes.
However, the foregoing method does not number the working services automatically on an ODUk protection ring. The foregoing method aims to let every node on the multiplex section ring understand the node configuration and node topology on the ring, and is independent of the specific service configuration. However, the ODUk protection ring cares how to allocate an identifier which is unique throughout the ring to each working service, and a consensus needs to be reached at both ends of the service without caring about the topology relation between nodes. If the services are numbered automatically by circulating the message around the protection ring, the implementation mechanism is rather complicated and is dependent on the communication between nodes, and is less reliable than expected.